Das fröhliche Buzzword-Bingo
Auf dieser Online-Plattform stellen wir Ihnen Konzepte vor, die alle das Zusammenspiel verschiedener Teile der IT-Landschaft eines oder mehrerer miteinander in Beziehung stehender Unternehmen behandeln. So wollen wir Licht in die unzähligen Abkürzungen, Schlagworte und Marketing-Begriffe bringen. Zu jedem dieser Konzepte finden Sie mehr Informationen auf den weiterführenden Seiten.
EAI
EAI
EAI steht für Enterprise Application Integration. Das Wort Enterprise meint dabei Unternehmen. EAI bedeutet, die verschiedenen Anwendungen innerhalb eines Unternehmens zu integrieren, sprich: miteinander zu vernetzen. Und zwar nicht, indem man jeder einzelnen Anwendung beibringt, mit jeder anderen zu reden. Vielmehr schafft man eine Zwischenschicht, eine Art gemeinsame Kommunikationsplattform, an die die verschiedenen Anwendungen angeschlossen werden (indem man Kommunikationsschnittstellen aka
Adapter schafft), sodass praktisch jeder mit jedem kommunizieren und zusammenarbeiten kann. Außerdem werden hier die Prozesse, die Regeln der Zusammenarbeit, definiert.
EDI
EDI ist die Abkürzung von Electronic Data Interchange, zu Deutsch elektronischer Datenaustausch. Scheint banal zu sein, ist aber recht komplex.
Man könnte sagen, schon das Senden eines Fax ist ein elektronischer Datenaustausch, denn immerhin wird das Fax, das Daten enthält, auf elektronischem Wege übermittelt. Dieses Beispiel hat allerdings wenig mit dem EDI zu tun, um das es hier geht. EDI meint, dass sich Applikationen, also Programme, weitgehend automatisch miteinander austauschen. Und zwar über Unternehmensgrenzen hinweg. Also ganz ähnlich wie EAI, nur zwischen zwei oder mehr Firmen und nicht innerhalb einer Firma. Wenn beispielsweise die Software eines Kunden eine Bestellung direkt als Datei zum Lieferanten schickt, wo diese ohne Eingreifen eines Menschen in dessen Bestellsystem landet, dann haben wir es mit EDI zu tun.
ETL/ELT
ETL/ELT
Die Abkürzung steht für Extract, Transform, Load und ist gleichbedeutend mit: Daten aus einem oder mehreren Systemen holen (extrahieren), umfor
men (transformieren) und in ein Zielsystem – üblicherweise eine Datenbank – laden (eigentlich müsste man eher speichern sagen, aber naja). ELT meint dasselbe, nur in veränderter Reihenfolge. Da werden die Daten erst in die Datenbank gepumpt und dann transformiert. Das Ganze kommt aus der Ecke des Data Warehouse. Und dessen Sinn wiederum liegt darin, Daten aus verschiedensten Quellen und Systemen einheitlich aufbereitet z.B. für Analysen und Statistiken bereitzustellen. Diese Einheitlichkeit wird durch die Transformation erreicht, die nicht nur die verschiedenen Formate der Quellsysteme in ein einheitliches Format für die Datenbank umbaut, sondern dabei auch gleich noch die Datenqualität verbessert (Dubletten eliminiert und ähnliches).
ESB
ESB
ESB meint Enterprise Service Bus, und das ist etwas eher Schwammiges. Ein ESB ist ein Konzept, eine Technologie, eine Infrastruktur oder auch eine Software, um die Integration verschiedener Anwendungen innerhalb eines Unternehmens, einer Abteilung oder eines Projektes zu unterstützen. Der
ESB ist also das, was bei EAI unten drunter liegen kann. Er verbindet verschiedene Anwendungen über Adapter miteinander, transportiert Daten zwischen ihnen und hilft auch beim Umbau (der Transformation) der Daten, damit sich die Systeme untereinander verstehen.
Er hat aber keine Ahnung von komplexeren Zusammenhängen und Geschäftsprozessen, denn ab da bewegen wir uns wieder im EAI-Bereich.
SOA
SOA
SOA ist eine Service Oriented Architecture, also eine dienstorientierte Architektur. Gemeint ist damit, dass viele verschiedene, womöglich über die ganze Welt verstreute, Anwendungen eine Schnittstelle bereitstellen, über die man Dienste von ihnen anfordern kann. Das kann ganz allgemein und global die Berechnung der Entfernung zwischen zwei Koordinaten sein oder ganz speziell nur im Firmennetzwerk die Anfrage, wann welcher LKW für eine Auslieferung bereitsteht. Will man tatsächlich Waren liefern, braucht man womöglich beide Dienste in Kombination, daher kann es einen weiteren Dienst geben, der die beiden anderen „unter der Haube“ aufruft. Wie der jeweilige Dienst implementiert ist, muss niemanden kümmern. Man sollte nur wissen, wie er zu nutzen ist. Und deshalb muss einzig die Schnittstelle des Dienstes zur Außenwelt bekannt sein. Ein Beispiel hierfür sind WebServices für den Datenaustausch.
Brauche ich so was?
Wenn Sie sich das Buzzword-Bingo durchgelesen haben, besser noch die detaillierteren Beschreibungen der einzelnen Konzepte, dann wissen Sie jetzt im Groben, was es mit Begriffen wie EDI, EAI oder SOA auf sich hat. Nun ist die Frage, ob Sie selbst „so was“brauchen können und wenn ja, was denn genau.
1.Frage: Wie sieht Ihre IT-Landschaft aktuell aus?
Es gibt nach wie vor Unternehmen, bei denen die IT aus ein paar PCs mit
Office-Paket und E-Mail-Programm besteht. Bestellungen kommen telefonisch
oder per Fax, Bestände hat der Lagerist im Kopf und Lieferscheine werden manuell ausgefüllt. Größere IT-Systeme? Fehlanzeige. Wenn das gut läuft und kein Geschäftspartner nach EDI-Prozessen verlangt, können Sie das Thema erst einmal abhaken und dieses Handbuch beiseite legen.
Die meisten Firmen arbeiten heute allerdings nicht mehr so, und wenn man eine gewisse Größe erreicht hat (oder mit entsprechend großen Geschäftspartnern arbeitet), bleibt irgendwann nichts anderes übrig, als einen Geschäftsvorgang nach dem anderen zu digitalisieren. Und wie schon in der EAI-Beschreibung angesprochen, geschieht das oft Stück für Stück. Irgendwann hat man dann eine bunte Sammlung von IT-Systemen, die alle unterschiedliche Datenformate und Schnittstellen haben und sich erst mal so gar nicht miteinander verstehen.Vielleicht sind Sie über diese Phase schon hinaus und haben in den letzten Jahren ein Sammelsurium von C-Programmen, Shell-Scripten oder gar Excel-Macros gebastelt, um irgendwie Daten von einem System zum anderen zu bekommen. Nicht zu vergessen die großen Kunden oder Lieferanten, die Ihnen seit einiger Zeit einfach Daten in einem (von denen!) bestimmten Format aufbürden. Da diese nun mit Strafzahlungen drohen, wenn Sie ihnen nicht endlich Ihre Daten im selben Format zusenden, steht bereits der Programmierer in den Startlöchern, um auch hierfür neue Programme und Scripte zu stricken, von denen jedes irgendwie (ein Glück, wenn er in einem halben Jahr selbst noch weiß, wie) eine spezielle Aufgabe erledigt. Und kommt ein Geschäftspartner mit etwas anderen Anforderungen, sind die nächsten paar tausend Codezeilen fällig.Bitte: Ziehen Sie die Notbremse! Sie kommen ja in Teufels Küche, wenn Sie so weitermachen! Ganz davon zu Schweigen, was passiert, wenn der Programmierer ausfällt. Zumindest bei Ihnen. Dann stehen Sie da mit Unmengen von Sourcen und ohne die geringste Ahnung, was da im Hintergrund abläuft. Oder, wie Sie jemals etwas daran ändern sollen.
2.Frage: Wie genau sind Ihre Anforderungen für die Zukunft?
Was passiert bis jetzt im Raum zwischen den einzelnen IT-Systemen und zwischen Ihrem Unternehmen und der Außenwelt? Das sollten Sie erst mal gründlich analysieren. Findet Kommunikation mit der Außenwelt praktisch nicht statt? Dafür sind aber Daten zwischen Ihren eigenen Systemen zu transportieren und abzugleichen? Das geht in Richtung EAI, evtl. auch ETL.
Kommen Bestellungen von draußen rein und müssen Bestellbestätigungen, Lieferscheine und Rechnungen verschickt werden? Geben Sie regelmäßig elektronische Kataloge an Ihre Kunden raus? Haben Sie LKWs auf der Straße, deren Positionen zu ermitteln sind (über GPS-Dienste)? Wann immer Daten von außen zu Ihnen und umgekehrt fließen sollen, ist das ein EDI-Thema.
Welche Art von Systemen steht bei Ihnen so rum? Datenbanken? SAP? Ältere WaWi-Software, die nur proprietäre Dateiformate ex- und importieren kann? Das entscheidet, wie und womit ein evtl. zu beschaffendes EAI- oder EDI-System kommunizieren können muss. Und wie spricht die Außenwelt mit Ihnen? Bisher bekommen Sie Excel-Dateien? Bleibt das so?
Sollte das System nicht auch allgemeine Standards beherrschen, um für die Zukunft gerüstet zu sein? Also EDIFACT, X12, XML etc.? Läuft alle Kommunikation per Mail oder sind sichere Übertragungswege wie AS2 oder SSH-basierte Kommunikation gefordert? Diese Punkte entscheiden, was das zu beschaffende System können muss. Und wenn Sie so drüber nachdenken kommt einiges zusammen, oder? Ein spezielles EDI- oder EAI-System reicht vielleicht nicht mehr, da die Aufgaben beider Bereiche abgedeckt werden müssen. Oh, nicht zu vergessen der regelmäßige Abgleich zwischen ein paar internen Datenbanken, ein ETL-Thema. Und dann gibt’s da ja noch Ihre Kunden, die gerne Anfragen z.B. zu aktuellen Lagerbeständen an Sie schicken möchten, was sich mit WebServices wunderbar erschlagen lässt. Dann können Sie entweder mehrere, auf den jeweiligen Bereich spezialisierte Tools einsetzen oder aber ein einziges, das zwar vielleicht nicht immer an die Bestleistungen von Spezialtools heranreicht, dafür aber alles unter einem Dach vereint.
3.Frage: Was soll das jeweilige Tool noch bieten?
Abgesehen von den Fähigkeiten im EAI-, EDI- oder ETL-Bereich gibt es auch noch andere Aspekte zu beachten: Darf das neue Tool ein ganz bestimmtes System voraussetzen (Linux/Unix, Windows, gar AS400/iSeries) oder erwarten Sie, dass es plattformunabhängig ist? Oder noch besser:
mit nur wenigen Klicks, ohne Programmierung, containerbasiert mit Docker installieren. Wie ist die Bedienbarkeit? Muss man erst eine Art Programmiersprache erlernen, bevor man die Software überhaupt zum Arbeiten bewegen kann, oder stehen die fachlichen Dinge im Vordergrund, während die Bedienung eher intuitiv erfolgt (bei diesem Punkt sollte man allerdings bedenken, dass EDI und EAI hochkomplexe Prozesse beinhalten, die selbst ein Fachmann nicht mit links „zusammenklickt“ – also bitte keine zu hohen Erwartungen an die Intuitivität!)?
Welche Rolle spielt die Lizenzierung in Ihrem Unternehmen? Lizenzen kaufen oder mieten? Am Besten wäre doch hochgradig flexibel. Also on-premise (Cloudanbieter) ohne technischen Mehraufwand. Hier empfehlen die EDI-Experten die Möglichkeit einer Dongle-basierten Installation.
Wie sieht das Monitoring aus? Hat man immer einen guten Überblick, ob alles rund läuft oder irgendetwas hakt und man eingreifen muss? Werden Sie bei Problemen aktiv vom System benachrichtigt? Wie wichtig ist Ihnen die Übersichtlichkeit? Warum nicht einfach das Dashboard der HTML5-Oberfläche ganz einfach über den Browser öffnen und damit schnell und unkompliziert alle wichtigen Systeminformationen anzeigen lassen. Egal mit welchem Device (ob Laptop, Tablet oder Handy), an welchem Ort und zu jeder Zeit. Die Devise: any place, any time, any device!
Bei geschäftskritischen Daten kommt es auch auf Datensicherheit an. Können z.B. Rechnungen über die gesetzlich geforderte Frist archiviert werden? Werden alle wichtigen Daten und Logs für Nachforschungen greifbar gehalten? Gerade im EDI-Umfeld können weitere, spezielle Anforderungen dazukommen. Zum Beispiel gilt in einigen Ländern immer noch die Pflicht zur digitalen Signatur bestimmter Daten (besonders Rechnungen). Innerhalb Deutschlands ist die Pflicht ja zum Glück schon längst wieder abgeschafft, aber wenn man mit bestimmten anderen Ländern Geschäfte macht, muss ein Signatursystem angebunden werden können. Und: Ein Standard-Tool bietet oft eine schier unüberblickbare Fülle von Funktionen, doch wie es der Teufel will, haben Sie noch eine ganz bestimmte Anforderung, die sich damit nicht „out of the box“ erfüllen lässt. Bestehen dann Möglichkeiten, das System selbst zu erweitern? Nicht jeder hat einen Programmierer im Haus, aber wenn, dann sollte die eingesetzte Software doch Schnittstellen bieten, über die man sich einklinken und eigene Erweiterungen unterbringen kann. Oder bietet zumindest der Hersteller an, solche Erweiterungen für Sie zu entwickeln?
Last but not least: Wie sieht’s mit dem Support aus? Wie schnell reagiert der Hersteller auf Probleme? Hilft er auch bei einfacheren Fragen weiter? Was hört man so über ihn? Stundenlanges Warten in der Kunden-Hotline war gestern. Warum nicht mit einem Klick direkten Support erhalten, mittels detaillierter Erklärfilme oder kontextbezogener
Dokumentationen.
Ist Ihnen bei Frage 1 aufgefallen, dass so ein Tool gar keine schlechte Idee wäre? Dann überdenken Sie die Punkte zu Frage 2 und 3 gut. Wenn Sie wissen, was Sie von der Software erwarten, die Sie suchen, schauen Sie sich auf dem Markt um, lassen sich von den verschiedenen Herstellern Ihre wichtigsten Szenarien bewerten (Geht es überhaupt? Wie viel Aufwand ist es?) und schauen Sie, welches Produkt die meisten Ihrer Wünsche erfüllt. Kann sein, dass es nicht das Billigste ist, aber besser Sie investieren einmal richtig, als immer wieder mit Mehrarbeit, Pannen und Zeitverlust dafür zu büßen, das falsche Programm gekauft zu haben.
Zur Abrundung können Sie sich auch im Netz oder bei anderen Unternehmen Ihrer Branche umhören, ob jemand eines der favorisierten Produkte kennt und was er über Produkt, Hersteller, Support usw. aus eigener Erfahrung zu sagen hat. Auch die EDI-Experten der Lobster GmbH stehen Ihnen bei allen Fragen rund um EDI und EAI zur Seite (information@lobster.de).
Was heißt darüber hinaus?
Zu Beginn dieses Handbuchs wurden u.a. die Begriffe EDI und EAI (Electronic Data Interchange und Enterprise Application Integration) beschrieben. Vereinfacht gesprochen handelt es sich hierbei um den Transport von Daten zwischen verschiedenen Software-Systemen und die Umwandlung dieser Daten in unterschiedliche Formate. Die Unterscheidung zwischen EDI und EAI ist dabei mehr organisatorischer als technischer Natur.
Im klassischen EDI/EAI beschränkt sich die Umwandlung auf syntaktische Änderungen. So wird z.B. aus XML, CSV, EDIFACT, … ein CSV, FixRecord, Excel, IDOC erstellt. Die Feldinhalte werden entweder unverändert übertragen oder formal umgewandelt. Beispiele für formale Umwandlungen sind unterschiedliche Datumsformate, Dezimaltrenner, Füllzeichen, Mengeneinheiten usw.
Mit zunehmender Komplexität der Schnittstellen wachsen jedoch auch die Anforderungen an die inhaltliche Logik der Schnittstellen. Aus diesem Grund werden immer mehr inhaltliche Funktionalitäten in die Schnittstellen verlagert. Die inhaltlichen Funktionalitäten können typische Geschäftslogik betreffen (Artikelnummer, Liefersperre, Lieferdatum prüfen, etc). In anderen Fällen ist vielleicht eine eigene Logik erforderlich, die ausschließlich für die Rückmeldung von Daten an den Absender gebraucht wird. Zusätzlich können bei der Konvertierung auch Daten erzeugt werden, die die bisher im Unternehmen vorhandene Logik erweitern bzw. ergänzen.
Nachfolgend sind einige Beispiele gelistet, die über den klassischen Begriff von EDI/EAI hinausgehen und die obigen Ausführungen verdeutlichen:
Referenzdaten prüfen
Bei der Konvertierung der Daten werden Stammdaten wie Artikelnummer und Kundennummer auf Gültigkeit geprüft. Sind enthaltene Werte ungültig, werden die Daten z.B. mit einer Fehlermeldung abgewiesen oder die falschen Daten mit Dummy-Werten ersetzt. Beim Ersetzen mit Dummy-Werten wird der erhaltene Wert entweder in einem Textfeld ins Zielsystem transportiert oder via E-Mail weitergegeben. Diese Lösung wird angewendet, wenn das Zielsystem Fehler in den Stammdaten nicht mit dem gewünschten Komfort behandeln kann.
Benachrichtigung an Fachabteilungen
Bei der Konvertierung wird geprüft, ob es sich um einen Eilauftrag handelt. Ist dies der Fall, wird zusätzlich zur Konvertierung die Fachabteilung per E-Mail benachrichtigt, um keine Zeit zu verlieren. Diese Lösung wird angewendet, wenn das Zielsystem den Benutzern eingegangene Eilaufträge nicht eigenständig, schnell oder deutlich genug anzeigen kann.
Aufbau eines Trackingsystems
Bei Unternehmen mit einer heterogenen Softwarelandschaft durchlaufen Aufträge nach dem Erhalt der Bestelldaten verschiedene Programme, bis die Waren schließlich das Unternehmen verlassen. Kommt es dabei zu Fragen nach dem Status, müssen Mitarbeiter diesen umständlich recherchieren. Dieser Aufwand kann vereinfacht werden, indem der Status des Auftrags während der Konvertierung zwischen den verschiedenen Programmen in eine Datenbank geschrieben wird. Die Recherche beschränkt sich damit auf ein einziges System. Auch bietet dies die Möglichkeit, sogar externen Partnern die eigenständige Recherche über ein Web-Interface zu ermöglichen.
Zwischenspeicherung von Referenzwerten des Partners
Der Partner sendet in seinen Daten Referenzwerte, die in den Rückmeldungen an ihn wieder enthalten sein müssen. Die Referenzwerte werden im Zielsystem nicht gebraucht und es sind auch keine Felder dafür vorhanden. Bei der Konvertierung werden die Referenzwerte in eine Datenbank zwischengespeichert und bei der Rückmeldung wieder ausgelesen (siehe oben ‚Anreicherung von Daten‘). Dank dieser Lösung kann man den Missbrauch von Feldern in Schnittstelle und Zielsystem umgehen. Auch ist so eine alternative Anpassung des Zielsystems vermeidbar.
Kumulierung von Bestellpositionen
Bei der Konvertierung werden z. B. mehrfach vorkommende Artikel in einem Auftrag oder mehrfache Lieferungen an den gleichen Kunden innerhalb einer Übertragung kumuliert. Hierbei handelt es sich um typische Business-Logik, die nur dann in der Konvertierung realisiert werden sollte, wenn das Zielsystem die erforderliche Funktionalität nicht leisten kann.
Daten für statistische Zwecke protokollieren
Bei der Konvertierung werden zusätzlich Daten wie Volumen, Versicherungswerte, Anzahl Positionen, etc. in eine Datenbank geschrieben. Diese Daten können später mit externen Programmen statistisch ausgewertet werden.
Zusätzliche Begleitdokumente für EDI-Abläufe erstellen
Bei der Konvertierung werden aus den Daten zusätzlich noch für Menschen lesbare Dokumente wie PDF oder Excel erstellt und an den Partner versendet. Bei manchen Firmen sind solche Dokumente z.B. bei Sammelrechnungen vorgeschrieben.